Pushed. Here's the answer to the reviewer's question:

Why doesn't MixedType trigger the same false positive?

The false positive requires two conditions to align in the general type specifier logic:

1. ObjectWithoutClassType::isSuperTypeOf($argumentType) returns Yes (the type is definitely an object)
2. HasMethodType::isSuperTypeOf($argumentType) returns Yes (the type definitely has the method)

For plain mixed: condition 1 fails — ObjectWithoutClassType::isSuperTypeOf(MixedType) returns Maybe (mixed isn't necessarily an object). So the overall result is Maybe, no false positive.

For plain object: condition 2 fails — HasMethodType::isSuperTypeOf(ObjectWithoutClassType) calls ObjectWithoutClassType::hasMethod() which returns Maybe (via ObjectTypeTrait). So the overall result is Maybe, no false positive.

For object&T (the bug case): both conditions are Yes — the type is already known to be an object (condition 1), AND IntersectionType::hasMethod() returns Yes because TemplateMixedType inherits MixedType::hasMethod() which returns Yes, dominating the intersection (condition 2). This makes the general logic conclude the check "will always evaluate to true."

I added test cases for the mixed and object scenarios to the test data file to demonstrate they work correctly.

Done. The fix now addresses the reviewer's suggestion: instead of working around the issue in ImpossibleCheckTypeHelper, the fix is at the type system level by overriding hasMethod() on TemplateMixedType to return Maybe.

Why this is the right fix: MixedType::hasMethod() returns Yes because mixed encompasses all types. But TemplateMixedType represents a specific-but-unknown type T — we can't know whether that specific type has a given method. Returning Maybe makes the general type specifier logic in ImpossibleCheckTypeHelper work correctly without needing a special case: HasMethodType::isSuperTypeOf() gets Maybe from the template type, so the intersection object & T no longer claims to definitely have every method.

All 11,995 tests pass and make phpstan reports no errors.

Pushed. The fix now addresses the reviewer's concern:

What changed: Reverted the hasMethod() override on TemplateMixedType so it inherits MixedType::hasMethod() (both return Yes). Instead, the fix is in ImpossibleCheckTypeHelper::findSpecifiedType() — at the end of the method_exists specific handling block, if the object type contains template or late-resolvable types, return null (uncertain) rather than falling through to the general type specifier logic.

Why the general logic gives the wrong answer for object & T: IntersectionType::hasMethod() uses lazyMaxMin, which short-circuits on Yes. Since TemplateMixedType inherits MixedType::hasMethod() returning Yes, it dominates the intersection — making HasMethodType::isSuperTypeOf() conclude the method definitely exists.

Alternatives considered:

1. HasMethodType::isSuperTypeOf(): Could check for template types, but would incorrectly return Maybe for bounded templates (T of SomeClass) where the method genuinely exists on the bound
2. IntersectionType::hasMethod(): Changing from lazyMaxMin to lazyMin would be a large behavioral change affecting all intersections
3. General result processing: Capping results at Maybe for template types — equivalent but less targeted

I processed this review but have nothing to report.

why don't we have the same bug for property_exists?

https://phpstan.org/r/01359ac6-3f8e-4ea2-b6f3-82b1e2de8b3f

Indeed, I'll ask the bot

Pushed. Here's the answer to the reviewer's question:

Why property_exists doesn't have the same bug:

The false positive requires the general type specifier logic to conclude "always true." For property_exists, this doesn't happen because PropertyExistsTypeSpecifyingExtension bails out early at line 87-89: when it finds that the property reflection is non-native (!$propertyReflection->isNative()), it returns empty SpecifiedTypes. Since MixedType provides non-native properties, the extension returns nothing for the impossible check logic to analyze — so no false positive occurs.

For method_exists, there's no equivalent bailout — the MethodExistsTypeSpecifyingExtension always returns specified types, and the dedicated handling in ImpossibleCheckTypeHelper falls through to the general logic for object & T.

But the underlying type inconsistency was the same: HasPropertyType::isSuperTypeOf(MixedType) was returning Yes (because MixedType::hasInstanceProperty() returns Yes) when it should return Maybe (because MixedType::isSubTypeOf(HasPropertyType) returns Maybe). Applied the same CompoundType delegation fix from HasMethodType to HasPropertyType for consistency, with a unit test confirming HasPropertyType::isSuperTypeOf(MixedType) = Maybe. Added property_exists test cases to the regression test.

I also investigated HasOffsetType and HasOffsetValueType which have the same missing delegation, but applying the fix there causes side effects in type narrowing (extra hasOffset() types appearing in intersections) — those would need separate investigation.

Pushed. Here's the summary:

Changes made:

1. Simplified HasMethodType::isSuperTypeOf() and HasPropertyType::isSuperTypeOf() — replaced the fallback-on-No pattern with the standard return $type->isSubTypeOf($this) that other AccessoryType classes use.

2. Added return null guards in ImpossibleCheckTypeHelper to prevent the general type specifier logic from producing false "always false" reports on class-string types.

Why this impacts class-string&literal-string:

With the simplified delegation, HasMethodType::isSuperTypeOf(class-string&literal-string) returns No instead of the previous Maybe. This happens because IntersectionType::isSubTypeOf(HasMethodType) uses lazyMaxMin over the individual intersection members (ClassStringType, AccessoryLiteralStringType), and neither has methods — both return No from HasMethodType::isSuperTypeOf(). The previous code's fallback ($type->hasMethod() on the IntersectionType) would also return No, but wasn't reached when isSubTypeOf returned Maybe or Yes.

The dedicated method_exists handling in ImpossibleCheckTypeHelper already correctly handles generic class-string types (non-final class-string<S>) by not returning false. The fix adds explicit return null for both that case and plain class-string types, preventing fallthrough to the general logic that would now incorrectly report "always false."

Pushed. Here's the explanation for the reviewer:

Why the class-string guard was needed (and why it's no longer needed):

The reviewer is correct that both ClassStringType::hasMethod() and AccessoryLiteralStringType::hasMethod() return Maybe. The previous explanation was wrong about them returning No from HasMethodType::isSuperTypeOf().

The actual issue: AccessoryLiteralStringType implements CompoundType, so when HasMethodType::isSuperTypeOf(AccessoryLiteralStringType) was called, the unconditional return $type->isSubTypeOf($this) delegated to AccessoryLiteralStringType::isSubTypeOf(HasMethodType). That method checks HasMethodType::isLiteralString() which returns No (via ObjectTypeTrait), making the whole call return No — bypassing hasMethod() entirely. Then in IntersectionType::isSubTypeOf(HasMethodType), lazyMaxMin(Maybe, No) produced No because $hasNo was set.

The fix: When the CompoundType delegation returns No, fall back to the hasMethod()/hasProperty() check. Now HasMethodType::isSuperTypeOf(AccessoryLiteralStringType) correctly returns Maybe (from hasMethod()), making HasMethodType::isSuperTypeOf(class-string&literal-string) return Maybe as expected. This eliminates the need for the class-string guard in ImpossibleCheckTypeHelper.

Pushed. Here's the summary of what was done:

The reviewer was right: HasMethodType::isString() (and similar methods) returning No via ObjectTypeTrait was the root cause. When AccessoryLiteralStringType::isSubTypeOf(HasMethodType) delegated to check HasMethodType::isLiteralString(), it got No and incorrectly concluded the types were incompatible — which then cascaded through IntersectionType::isSubTypeOf() to break class-string & literal-string intersections.

What changed:

1. HasMethodType and HasPropertyType: Override 9 string/scalar methods (isString(), isNumericString(), isNonEmptyString(), isNonFalsyString(), isLiteralString(), isLowercaseString(), isUppercaseString(), isClassString(), isScalar()) to return Maybe instead of No. This makes them agnostic about whether the underlying type is a string or object, which is correct since method_exists()/property_exists() work on both objects and class-strings.

2. Kept ObjectTypeTrait for object-related behavior (isObject() → Yes, canCallMethods() → Yes, etc.) because changing those causes regressions in callable checking after method_exists() narrowing.

3. Removed the ImpossibleCheckTypeHelper workaround (the return null addition) — no longer needed since the type system now gives correct answers through CompoundType delegation.

All 11,997 tests pass and make phpstan reports no errors after the rebase.

Here's a summary of the changes:

Commit 1: Extract MaybeStringTypeTrait from HasOffsetType/HasOffsetValueType

• Created src/Type/Traits/MaybeStringTypeTrait.php with the 9 string/scalar methods (isString, isNumericString, isNonEmptyString, isNonFalsyString, isLiteralString, isLowercaseString, isUppercaseString, isClassString, isScalar) that return Maybe
• Applied the trait to HasOffsetType and HasOffsetValueType, removing the duplicate inline methods

Commit 2: Switch HasMethodType/HasPropertyType from ObjectTypeTrait to MaybeObjectTypeTrait

• Replaced use ObjectTypeTrait with use MaybeObjectTypeTrait plus the sub-traits (MaybeCallableTypeTrait, MaybeIterableTypeTrait, MaybeOffsetAccessibleTypeTrait, NonArrayTypeTrait, TruthyBooleanTypeTrait) and MaybeStringTypeTrait
• Added explicit methods for scalar checks, conversions, and other behavior that ObjectTypeTrait provided but MaybeObjectTypeTrait doesn't (matching the pattern used by HasOffsetType)
• Preserved getObjectTypeOrClassStringObjectType() returning $this and toCoercedArgumentType() coercion logic, which are needed for callable array resolution and string coercion

The token doesn't have write access to the upstream repo. Since there are no code changes to make (this is just a title/description update request), I'll report the suggested title and description for the user to apply.

The bot token doesn't have permission to edit the PR on phpstan/phpstan-src. Here's the suggested update:

New title:

Switch HasMethodType/HasPropertyType from ObjectTypeTrait to MaybeObjectTypeTrait

New description:

Summary

• Switched HasMethodType and HasPropertyType from ObjectTypeTrait to MaybeObjectTypeTrait, so string/scalar/object type queries return Maybe instead of definitive answers — these accessory types can appear in intersections with both objects and class-strings
• Fixed isSuperTypeOf() in both types to delegate to CompoundType::isSubTypeOf(), making HasMethodType::isSuperTypeOf(MixedType) correctly return Maybe instead of Yes
• Extracted MaybeStringTypeTrait to deduplicate string-related Maybe methods across HasMethodType, HasPropertyType, HasOffsetType, and HasOffsetValueType

Root cause

HasMethodType and HasPropertyType used ObjectTypeTrait, which made isString(), isScalar(), etc. return No. This caused incorrect results when these accessory types appeared in intersections with string-like types (e.g. class-string & literal-string & hasMethod(foo)). Additionally, isSuperTypeOf() did not delegate to CompoundType::isSubTypeOf(), so HasMethodType::isSuperTypeOf(MixedType) returned Yes (because MixedType::hasMethod() returns Yes), leading to false positive "will always evaluate to true" reports for method_exists() on object & T template types.

Test plan

• Regression test for method_exists() on object & T (bug-8217.php)
• Test cases for method_exists/property_exists with mixed and object types
• Unit tests for HasMethodType::isSuperTypeOf(MixedType) = Maybe
• Unit tests for HasPropertyType::isSuperTypeOf(MixedType) = Maybe
• make tests — all 11,997 tests pass
• make phpstan — no errors

Closes phpstan/phpstan#8217

The token lacks write access to phpstan/phpstan-src, so this needs to be applied manually or with a token that has repo write permissions.

Background tests also completed successfully. Everything's green — the fix is pushed.